'/ personal rc< ollecl ion of the development of the 
COBOL programming language, complementing the 
formal histories. II ith this bat 'h ground, some 
possibilities and recommendations for the future of 
COBOL are given. t 


a view of The History of COBOL 


- j 

ii i 


11. II'. Berner 



At a time when the future of COBOL was less certain, 
Charlie Phillips received a package from Howard 
Bromberg, express collect. This is the tombstone that 
he paid SI 5 for. 
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ROM THE EDITOR ‘ 

his article first appeared in M. Berk's "The 
'rogrammer's COBOL"> Inter-ACT/McGraw- 
lill. It is reprinted with permission of the publ- 
ishers for the large number of people who 
jse the COBOL language without any real idea 
how it came to be. A historical framework, 
if not too dull, can add some interest to the 
1 ■'aily, work. 

The content has been verified by many of 
the active participants. The article attempts to 
give full credit to the various organizations 
that participated. Although the viewpoint (not 
bias, hopefully) is necessarily that of an IBM 
employee at the time, the author is now with 
Honeywell Information Systems, and can take 
much pride in their part of the development 
of COBOL. 

||:\ |t isn't all history, however. There are spme 
; predictions for the future. Some of these will 
I- come to pass without user pressures; some will 
not. Perhaps readers will see here some view- 
|| points and standards actions that they should 
r be supporting for their own best interests, and 
for the best interests of the computer-using 


T. 


world. 


I 


COBOL is a programming language known to a large 
J number of people who work in data processing. It is 
■ less known to the general public, and chemists becom- 
| ,ing involved in data processing for the first time are 
j prone to confuse it with Element No. 27. It is unique 
among the major programming languages in that factual 


j histories of its inception and development abound. 

! Standard summaries of the history are carried in all 
j official documents and in the manuals for specilic ma- 
j chine implementations, a policy of the original sponsors, 
•i A very complete history and summary of activities is 
to be found in the publication "American National 
Standard X3.23, COBOL". With this, one can track 
( meetings, participating personnel, and technical moti- 
r vation. Omitted are elements of personality, back- 
ground, competition, infighting, and signilicance to the 
j data processing world. Reading this history and others, 
’ one might conclude that there was never any excile- 
| ment, strategy, or corporate and individual struggles, 
j Not so. 


The very fact that these standard histories are carried 
in official COBOL documents is a key to understanding 
the COBOL effort. COBOL is intended to conserve 
costs and human resources, but any of the proprietary 
languages of its class could have done that, and very 
possibly they would all have grown and matured in 
the same way. IBM's FORTRAN became an industry 
standard because it was operational in volume before 
its competitors, and because IBM placed it in the public 
domain. In the business data processing world, the race 
was much closer. 

ORIGINS 

In time sequence of development, the three progenitors 
of COBOL were: FLOW-MATIC (from UNIVAC), Com- 
mercial Translator (from IBM, which ran into legal con- 
flicts with the original name COMTRAN), and AIMACO 
(from the Air Materiel Command in Dayton). 

FLOW-MATIC was an outgrowth of the A-series of 
algebraic and scientific compilers. The concept of the 
compiler is largely due to Dr. Grace Murray Flopper, 
who was in charge of these projects. The new series 
started as B-0 (B for business, as opposed to A for 
algebraic). A predecessor, BIOR (Business Input Output 
Rerun), was developed by a different group, becoming 
somewhat operational in 1955 April. FLOW-MATIC, as 
B-0 was renamed, became operational for the UNIVAC 
I and II in 1956 December. It was not what we would 
call today a commercial-gr v ade software product, and 
both language and compiler were still undergoing con- 
tinual change and improvement. 

The competitive threat potential of FLOW-MATIC 
did not go unnoticed at IBM, and some research was 
started in the Fall of 1956 on alternate solutions for a 
business language. The original approach tended to 
high-level operations and set notation, such as "MERGE 
FILEA WITH FILEB ON KEY 3" and "UPDATE THIS WITH 
THAT". I began to worry that this approach might take 
too long to bring to practicality, and asked Roy Gold- 
finger to develop a language with the more specific 
procedural capability of FLOW-MATIC, yet which would 
retain the set principles. Public notice of the Commer- 
cial Translator work was given to the SHARE group in 
1957 October, and Roy produced formal specifications 
in 1958 March. 

Reading the standard COBOL histories, one could 
get an impression that the early meetings were spon- 
taneous. Actually, Mary Hawes of Burroughs had button- 
holed Dr. Saul Gorn of the University of Pennsylvania 
at the Western Joint Computer Conference in San Fran- 
cisco on 1959 March 3-5, asking if he didn't think it was 
time for a common business language. Saul agreed and 
later that month held a meeting in his office at the 
(UNIVAC I) Computer Center. At a second meeting on 
April 8, various names were suggested for leadership. 
Grace Hopper proposed Charles Phillips of the Depart- 
ment of Defense. It seemed most reasonable for DOD 
to sponsor such an effort, which would need energetic 
leadership and neutrality, together with the stature (and 
pockelbook) to command the attention of the manu- 
facturers. I sent the agenda for the May 28 meeting to 
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the President of the Association for Computing Ma- 
chinery (probably as a needle for the disdain of bus- 
iness languages in the ACM Programming Languages 
Committee, although they were within their scope to 
develop). 

THE PEOPLE 

The Washington meeting of May 28 noted the separate 
development of three similar languages, and agreed 
that the example of ALGOL warranted an effort to 
develop a common business language. A steering (later 
executive) committee was formed with Phillips as Chair- 
man, Joe Cunningham of the Air Force as Vice Chair- 
man, Gene Albertson of U.S. Steel, Greg Dillon of 
DuPont, Mel Grosz of ESSO, plus the chairmen of the 
three task groups formed. They were: the Short Range, 
under Joe Wegstein (one of the founders of ALGOL) of 
the National Bureau of Standards; the Intermediate 
Range, under Gene Smith of the Bureau of Ships; and 
the Long Range, under Bob Curry of Southern Railway. 

I name these people here because they were all active 
for a long time in the COBOL world, and it is doubtful 
if history would have been the same without their ef- 
forts. Grace Hopper and I were appointed as technical 
advisors. My nontechnical contribution was the coining 
of CODASYL, for the Conference on Data Systems 
Languages. We can't find a single individual who admits 
coining the acronym "COBOL". 

EARLY RESULTS 

Some of the old hands laughed disbelievingly when the 
Short Range task group was charged to come up with a 
composite within three months. Still, they worked as- 
siduously, and held twelve meetings between June 23 
and the end of August. Membership included represent- 
atives of Burroughs, IBM, Minneapolis Honeywell, RCA, 
Remington Rand UNIVAC, and Sylvania, plus the Air 
Materiel Command and the Bureau of Ships. The report 
was presented to the Executive Committee on Septem- 
ber 4. Wegstein said charitably that "It contains rough 
spots and requires some additions". It was, in fact, a 
committee hodgepodge, which hardly caused IBM to 
abandon plans for Commercial Translator. The task 
group was enjoined to get it in shape by December 1, 
and to continue in existence beyond that to monitor 
implementations on various computers. 


w.’Mik Currv . j 

COMPLICATIONS i 

Now uncertainty enters. A news item in June had stated 
that a new company was being formed (Computer 
Sciences Corporation) whose first responsibility would 
be the construction of a compiler for the Honeywell 
800. Joe Wegstein gave details to the Executive Com- 
millee on September 4, when he presented his report. 
Unquestionably the Intermediate Range Commitlee (the 
task groups had by now been upgraded) was dismayed 
by the first results of the Short Range Committee. One 
of its members was Dr. Richard Clippinger of Honey- 
well, who was able to furnish a copy of the specifica- 
tions for the Honeywell Business Compiler Language 
(later FACT) at their October 8 meeting. FACT was a 
medley of the three approaches tried for Commercial 
Translator: (1) modular report, file maintenance and 
sort generators, (2) high-level operators such as "UP- 
DATE", and (3) the English language procedural state- 
ments. As a language, it was undoubtedly rich and well- 
defined for that period; one could well say that it was 
ahead of its time. {; 

FACT was too attractive to the Intermediate Range 
Committee in the face of the shortcomings of the first 
COBOL report; they endorsed FACT to be the basis of 
the common business language. The word spread with 
shock waves. IBM and UNIVAC, having consented to 
work on a composite, could scarcely be happy to scrap 
the work and accept in toto the language of a com- 
petitor. General doubt was expressed about the sanity 
of the Intermediate Range Committee, which retaliated 
by convening again just five days later and reaffirming 
its support of FACT: 15 in favor, 1 opposed, and 2 j 

abstaining. •; 

Unfortunately for FACT, the implementation failed 
the language. Bob McDowell (first with Computer Sci- 
ences Corporation, and later Honeywell's liaison with 
them) says that this was caused primarily by an attempt 
to force the compiler into too small a configuration, 
resulting in missed schedules and customer problems 
(unlike 3rd-generalion customers, they were not re- 
signed to such difficulties). He feels that if FACT had 
been at least partially demonstrable at the time, the 
battle may have been won. However, in view of the 
competitive situation, the war might have been lost. 

As it turned out, FACT was not operational until a 
year after the first COBOL processors. Nevertheless, the 
language was a substantial contributor to COBOL, and 


this i‘ 
trast, 
tion r 
and tl 
Air h 
subm 
cepte 
mino 
Philli 
The i 
the ( 
Print 

COE 

Desp 
factu 
meni 
ever, 
in In 
semn 
presc 
sumi 
A LG ' 
langi 
by G 
unar 
Tl 
elen 
Tran 
and 
piler 
ing I 
mitt’ 
Tran 
extr; 
FOR 
on 
COf 
vey 
Trar 
clair 
decl 
mac 
A 
mor 
peri 
ing 
exis 
IBK 
I a to 
tor 
pro 1 
Trar 
fror 
mill 
nou 
cial 
spir 
a si 
aco 
mit 


132 HONEYWELL COMPUTER JOURNAL 


p 


!• 


this is reflected in the later acknowledgments. In con- 
trast, AIMACO as a language was not; it was a deriva-. 
tion of B-0 undertaken as a joint project with UNIVAC, 
and the contribution here was from the personnel of the 
Air Materiel Command. The Short Range Committee 
submitted its next report in 1960 January. It was ac- 
cepted, subject to editing for "typographical and other 
minor errors". The editing committee was chaired by 
Phillips, together with Wegstein and Betty Holberton. 
The minor work took from January through April, and 
the COBOL 60 Report was issued by the Government 
Printing Office in June. 

COBOL 60 

Despite the inadequacies of the Report, the list of manu- 
facturers announcing or committing to COBOL imple- 
mentations grew. It was simply the thing to do. How- 
ever, many qualms were felt about a language defined 
in large part by example rather than by syntax and 
semantics, particularly at IBM, whose John Backus had 
presented his metalinguistic notation (BNF) the previous 
summer. General Electric's Charlie Katz, another old 
ALGOLer, warned (in the public announcement of their 
language GECOM) that while COBOL could be accepted 
by GECOM, it was not yet developed to the point where 
unambiguous interpretation was possible. 

The official IBM position on COBOL was a critical 
element for acceptance in the industry. Commercial 
Translator had been announced for the 7070, 709/90, 
and 705 III. Barry Gordon was responsible for the com- 
piler implementations. Roy Goldfinger and I were work- 
ing both within IBM and within the Short Range Com- 
mittee to reduce the differences between Commercial 
Translator and COBOL, allowing the former to have 
extra features, particularly the computational forms of 
FORTRAN. As a result, the GUIDE organization was told, 
on 1960 January 27, that IBM would include basic 
COBOL in Commercial Translator. The February 15 sur- 
vey by the SHARE organization showed Commercial 
Translator as IBM's version of COBOL (oddly, IBM 
claimed only 80% machine independence, Honeywell 
declined to quote on FACT because it was for a single 
machine, but Wegstein claimed 100% for COBOL). 

At the February 17 meeting of SHARE (XIV), Al Har- 
mon, Manager of Applied Programming (and my su- 
perior), said: "It appears that time schedules for achiev- 
ing a version of COBOL that will be satisfactory for all 
existing and proposed computers would unduly delay 
IBM's production of processors for Commercial Trans- 
lator. We are revising our present Commercial Transla- 
tor manual to represent our best solution to these 
problems. Our intentions are to revise the Commercial 
Translator language to include new developments, both 
from our own efforts and those of the COBOL com- 
mittee". My verbiage for the official IBM position, an- 
nounced in Datamation magazine, was "The Commer- 
cial Translator is being reworked as nearly in the COBOL 
spirit as possible ... to ensure that the end result will be 
a single workable language for data processing". The 
accent on workable came from the Short Range Com- 
mittee's reluctance to admit the many demonstrated 


logical flaws that we found in their specifications. Joe 
Cunningham reported, in 1963 March, that when the 
total cleanup had been«made, the syntax was just as de- 
finable as ALGOL, bu*t the semantics were prone to 
ambiguities. 

All of this was very noble and elder-statesmanly. The 
only problem was that there were two versions of Com- 
mercial Translator within IBM: the one that Tom Gians, 
Roy Goldfinger and I specified to merge into COBOL, 
or perhaps even reconcile to identity; and the other that 
was written by Barry Gordon, that diverged. Because 
Gordon was in charge of compiler implementation, our 
good intention came to naught. Seven pages of dif- 
ferences between the two versions were compiled. I 
recall trying for free form in the statements in order to 
avoid punch card limitations, which would be quite 
handy for terminals today. 

At the 6th meeting of CODASYL on 1960 April 7, 
NCR and General Electric announced their intentions to 
build COBOL compilers. The latter would make it part 
of GECOM, which also had algebraic statements like 
Commercial Translator (antedating PL/I), and a tabular 
structure facility. Because new manufacturers were ask- 
ing for participation, Dr. Hopper and I were discharged 
as advisors, to avoid any appearance of partisanship. 
In May, Jack Jones of the Air Materiel Command an- 
nounced the start of an UNIVAC 1105 COBOL. By Sep- 
tember, there were 11 manufacturers represented on 
CODASYL and all had indicated that they would supply 
compilers (the original six plus Bendix, CDC, GE, NCR 
and Philco). C.G. Holland-Martin of International Com- 
puters and Tabulators had sent a representative to the 
first CODASYL meeting, and ICT (now ICL) announced 
a COBOL compiler in October, superseding their own 
CODEL language. 

The internal dissent at IBM kept building, and outside 
pressures were felt from the user groups. The problem 
escalated to T.V. Learson, now IBM's Chairman of the 
Board, who solved it in the style of one who has access 
to sufficient spendable money. IBM would do both, 
and work toward reconciliation. Accordingly, Al Har- 
mon told the 1960 May 17 meeting of GUIDE that IBM 
would supply COBOL compilers for the 705 II (without 
IOCS), the 705 III, 7080, 7070, and 709/90, but declined 
to give delivery dates. He outlined the two-phase solu- 
tion of Learson: first a modified Commercial Transla- 
tor and then a conversion to COBOL. This was most un- 
satisfactory to GUIDE, which resolved that IBM should 
stick to its original statement, and that there should be 
only one compiler per machine, with COBOL an in- 
tegral part of Commercial Translator. 

IBM did not do so, however. Not because it would 
not, but because it could not. Roy Goldfinger made an 
extensive comparison in 1960 July between COBOL and 
the version of Commercial Translator implemented by 
Barry Gordon, showing that the original objective was 
missed by a wide margin. To give IBM management 
their due, they were honestly chagrined to find that 
good intentions do not guarantee compatibility in pro- 
gramming languages! 
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Difficulties persisted. II3M finally announced their 
COBOL production schedules on 1960 October 1, but 
it was not until 1962 September that the success of 
COBOL was sufficiently apparent for Bob Ruthrauff to 
tell SHARE XIX that "We intend to make COBOL our 
development language and. plan no further develop- 
ment of the Commercial Translator language itself". 
IBM did not want to put Commercial Translator under 
the 7090 operating system, but said it would negotiate 
with diehard users. (Actually, the situation would never 
have come to this had not the 7090 compiler for Com- 
mercial Translator, done by a West Coast group under 
the direction of Dr. Richard Talmadge, been so good 
compared to the COBOL compilers existing then.) In 
1963 February, SHARE abandoned all hope for Com- 
mercial Translator and prepared to switch existing pro- 
grams over to COBOL via translation routines and some 
hand work. Honeywell went through much the same 
difficulties and extra expense; FACT was completed and 
customers were supported, despite their parallel sup- 
port of COBOL. 

VICTORY? 

The participants in the COBOL effort did not disdain 
publicity. The New York Times of 1960 August 26 an- 
nounced RCA's victory in the "Computer Translating 
Race", although the language was not full COBOL by 
any means, nor was the compiler released until Decem- 
ber, when RCA and UNIVAC held a joint compatibility 
demonstration for the public. Both computers operated 
the test programs identically, UNIVAC II on December 
6 and RCA 501 on December 7. Nevertheless, Datama- 
tion announced that RCA was "making publicity capital 
out of The Sacred Project" and had "made off with the 
first publicity marbles". IBM received similar publicity 
with the COBOL 61 compiler on the 1410. 

QUALITY PROBLEMS 

In general, the compiling techniques of early COBOL 
processors were primitive, resulting in very low com- 
pilation rates. Navy evaluations reported in 1962 May 
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showed five compilers ranging from 3 to 11 statements 
per minute. Measurements in mid-1964 showed a range 
of 11 to 1000 statements per minute. Hardware did not 
get that much faster in two years, so we must conclude 
that we found out how to build compilers belter. At 
this time, it was first noticed how drastically compiling 
rate varied with the size of store (memory) available, 
and how much variance there was in compiling cost, 
which ranged in this study from $0.23 to $18.91 per 
statement. Presently we are in the range of several 
thousands of statements per minute, and the costs are 
very much lower. 

STANDARDS 

Publications via the CODASYL route were COBOL 60, 
COBOL 61, COBOL 61 Extended, COBOL 65, CODASYL 
COBOL Journal of Development-69, and CODASYL 
COBOL Journal of Development-70. The original , in- 
tent was to update yearly, but this was changed with 
the advent of formal standardization, in early 1963. The 
CODASYL COBOL committee concentrated on devel- 
opment, leaving the intermediate and formal stand- 
ardization to the standards bodies. The European Com- 
puter Manufacturers Association (ECMA) set up Tech- 
nical Committee 6 to deal with COBOL, corresponding 
to American National Standards Committee X3.4.4, 
which was responsible for developing a COBOL stand- 
ard (Howard Bromberg, Chairman). These two com- 
mittees worked jointly to produce twelve COBOL In- 
formation Bulletins. 

Under the Brooks Bill, US Public Law 89-306, Fed- 
eral Information Processing Standards are the three-way 
responsibility of the National Bureau of Standards 
(NBS), the Bureau of the Budget (now Office of Man- 
agement and Budget), and the General Services Admin- 
istration. The first man in the NBS position was Norman 
Ream, previously of Lockheed. Short funding at NBS 
prevented the monitoring and measuring efforts sched- 
uled there originally. These difficulties were surmounted 
when Ream was appointed Special Assistant to the Sec- 
retary of the Navy, for he was imbued with the idea that 
standards would not be too effective without a means 
of checking conformity. Many compilers were claimed 
to be COBOL, but, without a Truth In Packaging law or 
detection device, the user was sometimes misled. 
Ream's ingenious solution was to call back to active 
service Commander Grace Hopper, USNR (Ret) to lead 
the accelerated effort in COBOL standardization for the 
Navy. Grace was to return to active duty for six months 
starting 1967 August 1. Only one thing was wrong with 
the memo announcing this move: she did not get out in 
1968, nor in 1969, nor in 1970, when her orders were 
reissued to read "indefinite". As a result, the Navy has 
constructed comprehensive COBOL certifiers that are 
available to anyone. 

By being brought under standardization control, 
COBOL could profit by being related to other informa- 
tion processing standards. To give an example, CO- 
DASYL had an early report on the 1960 January 13 
meeting of the American Standards Association, at 
which Committee X3, on Computers and Information 
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Processing, was authorized. Character sets were very 
prominent in the discussion. FLOW-MATIC had 63 
characters available, due to the UNIVAC computer, 
whereas IBM was limited to 48, due to the punch card 
set at that time. Furthermore, the collating (ordering) 
sequences were different between the several equip- 
ments, and none of the existing sequences survived in 
the American Standard Code for Information Inter- 
change (ASCII). Yet COBOL has statements in the lan- 
guage which give different actions depending on the 
collating sequence of the hardware! For reasons un- 
known to me, CODASYL chose to ignore this problem, 
and it is still not resolved. 

A COBOL specification has been adopted by the In- 
ternational Standards Organization, which refers to 
standards as Recommendations. Through the efforts of 
an international editing committee, and careful arrange- 
ments by the standards bodies, it is ihe same as the 
American National Standard. ECMA also contributed 
heavily with a formal description of the syntax of CO- 
BOL, which was invaluable in reducing ambiguities and 
validating constructs. 

WHAT NOW? 

Ftere we are, beginning a new decade with a regularized 
COBOL world in both French and English. One might 
think that the future would hold no surprises. Theoret- 
ically, COBOL could continue to maintain a prominent 
position in computer usage. There is an organizational 
structure for development, and several standardization 
bodies to normalize the changes and additions as they 
are developed. Practically, however, there are some 
strong factors opposed to its immortality: 

11 PL/I, a competing language, has been introduced 
and has attained substantial usage. PL/I also has 
development and standardizing bodies, at least in 
the US and in ECMA. It appears that COBOL pro- 
grams are translatable to PL/I programs with some 
difficulty, but not too much more than from 
FORTRAN II to IV programs. 


■ Although COBOL now has additions for data com- 
munication and data manipulation, they are ap- 
pended to the same old COBOL, structure orig- 
inated for a uniprogramming environment. As I 
warned in an address to the 10th Anniversary 
Meeting of CODASYL, data communication and 
manipulation are but different aspects of general 
data movement, and should be unified and com- 
mon to all programming languages that must co- 
exist in the same multiprogramming environment. 
PL/I, COBOL, and FORTRAN, having different 
development committees, contain data commun- 
ication facilities that are not common or similar, 
and yet they must coexist under a single operating 
system. As the data base becomes king, there is 
really no need for more than one data procedure 
language. The user pays heavily for this language 
plurality. 

■ The concept of levels may prove vitiating in a 
communications world. If interchange is stressed 
too heavily, the tendency will be to write pro- 
grams in the lowest level of COBOL, in order to 
assure the widest usability on a maximum num- 
ber of computers. This is akin to Gresham's Law, 
and low-level programs will drive out high-level 
capability. This would be unfortunate, for those 
lower levels are really unnecessary. The only (and 
original) reason for their existence is to permit 
COBOL compilation on small computers, which 

. is something tha’t small computers are particularly 
unsuited for. It is far better to use the full power 
of a high level of COBOL, hook up by commun- 
ications to a remote compilation service, and get 
back an object program, the running of which 
does not tax machine capacity the way compila- 
tion does. 

n Finally, COBOL and the other languages all pos- 
sess a serious defect for public usage of data: they 
carry the data description in the program. For in- 
terchange and multiple use of public data, the 
data must be self-descriptive, and the description 
must be carried along with the data on the storage 
medium (i.e., disk or tape). Some corresponding 
change in the structure of these languages is 
cerlain. 

However, these technical difficulties should not deter 
the working user from extensive use of the COBOL lan- 
guage. For every successful user there are still several 
floundering in the morass of emulation because they 
just could not bring themselves to break away from 
machine language. The problems of program transfer- 
ability are great, and the losses from not using trans- 
ferable languages such as COBOL run well over $1 bil- 
lion each year. We find countless examples of program- 
mers who have moved on, leaving programs that are 
undecipherable for maintenance or modification. Had 
they been written in COBOL, they would have had more 
than zero salvage value. 

In my opinion, emulation is a crutch that never lets 
you get over the handicap. Fight wastage of human re- 
sources; COBOL is a great weapon. 
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